1. Field of the Invention
This invention relates to conversational transactions and more particularly relates to enabling conversational transactions in a Business Process Choreography environment using Information Management System Connect.
2. Description of the Related Art
Many businesses are heavily invested in storing data in legacy-type database management systems such as IBM's Information Management System (“IMS”). With the rise of open standards, businesses desire to access data and fulfill service requests using internally and externally available web services. To avoid the expense and inconvenience of moving data in existing legacy database management systems to a service oriented architecture (“SOA”) system, a need exists to access data in legacy database management systems using web services and the new Java Platform Enterprise Edition (“J2EE”)-based applications.
IBM's Business Process Choreography is a tool that may be used to address some of the problems of data access in a web service environment. IMS Connect provides a gateway to IMS for Transaction Control Protocol/Internet Protocol (“TCP/IP”) connections to an application server. IMS Connector for Java (“IC4J”) is a resource adapter available on the application server for Java clients to access an IMS via IMS Connect. An application server may be an IBM WebSphere Application Server, a BEA WebLogic Server®, and the like. An application server may include a business process server, such as IBM's WebSphere Process Server (“WPS”), and may be able to process business transactions.
One important type of business transaction is a conversational transaction. A conversational transaction is a business transaction made up of several steps. A conversational transaction (“CT”) does not process an entire transaction at one time, but is made up of several steps. An application running on IMS or another database management server capable of conversational transactions (“CT application”) divides processing of a CT into a connected series of terminal-to-application-to-terminal interactions.
For example, an IMS running a CT application may receive a first transaction request from a Java client through an IMS Connect. The CT application processes the request and returns a response to the Java client, typically on the same socket of the IMS Connect that received the request. Typically, a socket of an IMS Connect in communication with a Java client is a TCP/IP connection. The Java client then makes a second request to the IMS and the IMS responds. This conversational transaction continues until the Java client signals an end of transaction to the IMS.
In the prior art, the IMS Connect receives a conversational transaction identifier (“CTID”) and a conversation indicator. The CTID is generated by the IMS to internally keep track of the CT. One name for the CTID is a Transaction Instance Block (“TIB”) token. When a transaction is a conversational transaction, the IMS passes the TIB token or CTID back to the IMS Connect with the conversation indicator. Typically the conversation indicator is a flag that signals the IMS that the transaction is a CT. In prior art systems, the IMS Connect stores the CTID and maintains or persists the socket connection to the Java client until the conversational transaction is completed. The IMS understands that any transaction request received over the persistent socket pertains to the same CT. When a subsequent request is received from the Java client over the persistent socket connection, the IMS Connect attaches the CTID to the request and passes the request and the CTID to the IMS.
In today's service oriented architectures, however, service requests may be routed through any number of pathways to an intended target. In an SOA, an IMS Connect may receive a first CT request from a Java client and transmit the request to the IMS. The IMS Connect would then receive the CTID and conversation indicator along with a first CT response, store the CTID, pass the first CT response to the Java client, and release the socket connection to the Java client. The IMS Connect may then receive a second CT request pertaining to the same CT over a second socket connection. The IMS Connect would not recognize the second CT request as pertaining to the first CT and would pass the second CT request to the IMS without the corresponding CTID. The IMS would then generate an error, not knowing the CT to which the second CT request belongs.